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ABSTRACT 


When embarking into the design of a new launch vehicle, engineering models of expected 
vehicle performance are always generated. While many models are well established and understood, 
some models contain design features that are only marginally known. Unfortunately, these analytical 
models produce uncertainties in design margins. The best way to answer these analytical issues is 
with vehicle level testing. The National Aeronautics and Space Administration respond to these 
uncertainties by using a vehicle level system called the Development Flight Instrumentation, or DFI. 
This DFI system can be simple to implement, with only a few measurements, or it may be a 
sophisticated system with hundreds of measurement and video, without a recording capability. From 
experience with DFI systems, DFI never goes away. The system is renamed and allowed to continue, 
in most cases. Proper system design can aid the transition to future data requirements. 

This paper will discuss design features that need to be considered when developing a DFI 
system for a launch vehicle. It will briefly review the data acquisition units, sensors, multiplexers and 
recorders, telemetry components and harnessing. It will present a reasonable set of requirements 
which should be implemented in the beginning of the program in order to start the design. It will 
discuss a simplistic DFI architecture that could be the basis for the next NASA launch vehicle. This 
will be followed by a discussion of the “experiences gained” from a past DFI system implementation, 
such as the very successful Ares l-X test flight. Application of these design considerations may not 
work for every situation, but they may direct a path toward success or at least make one pause and 
ask the right questions. 
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Introduction 


Development Flight Instrumentation has been a component of a launch vehicles avionics suite from 
pre-Saturn to the present. Engineers will design systems and components using the best engineering 
practices and modeling, but there still remains the unknown of “did I miss something” in the design. 
This is where DFI abounds. A DFI system can consist of a handful of measurements to a vast, 
elaborate networking of spider harnesses, sensors and data systems. This is dependent on the 
complexity of the launch vehicle and how well the engineering models have been refined in the past. 
But in all cases, an early, system engineering team is the key for success. It starts at the beginning 
of a new program. Not one or two years after the program starts. NASA typically starts DFI 
programs after the design has matured somewhat. And this causes the DFI team to have to “catch- 
up” and do so with fewer resources. 


System Engineering 


At the start of a new design, there needs to be in place a strong systems engineering and 
management team. This team needs to be considered a high performance team*. (*Katzenbach and 
Smith). They need to understand how high level flight test objectives will flow down, and are 
supported, by the DFI design engineers. They must be critical thinkers. They need to know the 
purpose for the system. And the purpose needs to be significant and realistic. They need to 
understand the problems that might arise from any derived design. They need to examine data, 
concepts and make assumptions as well as understand any implications of those assumptions. They 
need to rely on past experiences, both positive and negative. The system engineering team must 
produce a set of unambiguous requirements. 

So what would be a good set of high level requirements? “A system for model validation shall be 
provided by the launch vehicle.” Well, maybe. How about, “The launch vehicle shall contain a system 
of measurements for gathering engineering data.” These are extremely high level requirements that 
might point to a DFI system. But the requirements like, “A DFI system shall be able to transmit and 
record data, up to 20 Mbps” and “The DFI system, excluding harnessing, shall weigh no more than 
500 pounds” are requirements the engineering team needs to design a system. Even a 
programmatic requirement like, “The complete DFI system shall not exceed $1.4 million” is useful. 
These requirements set a “bogie” or a target to design too. But these “bogie” requirements tend to be 
levied too late. And this leads to a less than ideal DFI system design. A minimum of “must have” 
requirements should be: 

1 . A DFI system will have transmit bandwidth of X Mbps for telemetry. 

2. The DFI system shall weigh no more than Y pounds, including all components. 

3. The DFI system shall utilize OTS (off-the-shelf) components where practical. 

4. The environmental requirements for the DFI system are Z. 

5. DFI measurement requirements shall be justified based on technical needs as opposed to 
programmatic needs. 

The variables X, Y and Z must be known or provided at the earliest phase of a DFI system design. 
The Ares l-X test flight program was a good example of how DFI was not considered in the beginning. 
The original program was not to gather data, but to achieve lift-off and separate successfully. It was 
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not until design engineers elevated their concerns, to well above the program manager, that DFI was 
added to the program. When it was added, it was at a lower cost “bogie”, which limited the system. 
Needless to say, the system was designed, but sensors were removed from the measurement list, 
DAUs were reduced, etc., but the flight was very successful. It is very important that the DFI system 
be considered at the beginning of a program and that “bogie” type requirements are levied. 

Design Features 


One of the most important design features of a DFI system is having a well thought-out DFI System 
Specification. This specification should define the general functions for and requirements of each 
component that makes up the system. It should contain operational scenarios and concepts as well 
as organizational and management relationships (roles and responsibilities). The operational 
concepts can also be provided as a separate document and is sometimes referred to the Concepts of 
Operations (CONOPS) document. These documents should describe how a specific set of DFI 
capabilities would be used to achieve the desired DFI design and performance. 

Another feature is procuring hardware with the proper level of available test data. Many OTS 
manufacturers design hardware to fit a majority of their customers. They can operate to benign 
environmental requirements. In the case of NASA, we use hardware in harsh environments which 
tends to push technology to the fringe and perhaps beyond most hardware capabilities. This poses a 
set of issues in developing a DFI system. Not only is this issue technical but it becomes project as 
well. More money is required and the schedule is impacted to meet the DFI system requirements. 
NASA’s use of hardware will lead to costly testing if the environmental requirements are not provided 
early in the programs life cycle. 


Hardware 


The DFI system purpose is to sense and record flight operational systems within a particular launch 
vehicle or system. DFI system hardware can vary, but it mainly contains a common set of critical 
components. There are data acquisition units (master and remote), batteries, sensors, telemetry 
systems (video and data), harnessing, mounting provisions, cameras, multiplexers and recorders, 
and power dividers. Not all these components are required, but they are the typical components on a 
NASA DFI system. For the purpose of explanation, a non-proprietary, DFI system is shown in figure 
1 . This architecture was in contention for a flight test vehicle but not implemented for a follow-on test 
flight. The program was redirected shortly after the successful Ares l-X launch and thus canceled. 
This hardware is available commercially to anyone, thus is not proprietary in its description. Only 
hardware function names are listed on the drawing. 

The Figure 1 architecture shows OFI data passing through the DFI system. In reality, this would not 
be allowed. None the less, this is an option. The DFI system could possibly take out the OFI system 
in an anomaly. 

The data acquisition units are the heart of the DFI system. They are available as OTS components or 
can be designed from the ground up. They will contain all the signal conditioning for all the sensors 
being measured. These units provide the data format types, such as PCM or Ethernet. They can have 
user changeable signal conditioning cards or be designed for a very specific application. NASA 
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launch vehicle requirements change from launch to launch, so a specific application design is not cost 
effective to NASA. 

A battery and a power distribution system (PDU) are required, because NASA has a requirement that 
a DFI component cannot share resources with operational flight resources, sometimes labeled 01 or 
OFI. As stated at the beginning, a DFI system has a requirement to “Do No Harm” to the flight 
system being measured. 

The telemetry system, TMS, is the components that take the PCM data and passes it to a ground 
station. This hardware again is separate from 01 hardware, because of the “Do No Harm” 
requirement. The TMS and matching ground assets are the main requirement drivers that drive 
overall DFI measurement capabilities. In NASA’s case, many components are lost to the sea after 
they perform their job, thus recording the data on the vehicle may not be an option. 



Figure 1. Proposed DFI Architecture 


Sensors transduce a physical phenomenon into an electrical signal that can be read by the data 
acquisition units. Sensors can vary, but typically sensor types are vibration, acceleration, force, strain, 
temperature, heat flux and pressure. There are sensor systems as well. The DFI system can collect 
data from navigation systems or air data systems. Cameras are sometimes considered sensors but 
because of their high bandwidth requirements, they are usually telemetered and recorded separately 
from the other measurement data. But in some cases, they can be combined with measurement 
data. On Ares l-X, the DFI system switched between several cameras. They were converted into a 
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PCM stream and combined before being transmitted to ground with its own telemetry system. But all 
the converting and combining was handled by the DFI hardware. Cameras are difficult to use on a 
DFI system, but they are necessary to have. An early implementation plan is very beneficial for 
including cameras in a DFI system. 

The recorder is that component which captures and stores data from the measured sensors. 

Hopefully a system can benefit from its use. This component needs rigorous testing before 
implemented into the design. Timing, buffering and synchronization are critical for future analysis. 
While the Data acquisition units are the heart of the DFI system, the recorders are the brains. And 
sometimes, two heads (brains) are better than one. If the recorder fails, even in a small way, precious 
data loss is the result. Recorder issues will be discussed later. 

Not all DFI systems will need a multiplexer. If the system is of a few measurements, then this 
component is not required. But for more complex systems, it is. They are used to squeeze or 
combine data into data streams before they are telemetered and/or recorded. They are also useful 
when dealing with cameras. 

All DFI system components are to be mounted somewhere on the launch vehicle. Because of their 
various environmental requirements; mounting schemes for each component need to be considered. 
Sensors can be mounted in bosses or inserts. Harnesses can be p-clamped to the structure. In 
some cases, pressure sensors can be p-clamped as well. Data acquisition units require mating to a 
surface that meets certain environmental mitigation as well as flatness requirements. Placing 
unnecessary torque on a data acquisition unit may cause the components or cards within the box to 
lose contact. Mounting is often overlooked or not considered until late in the program. 

All the system is held together with the massive harnessing. These are the blood vessels of the 
system. Typically, it is the heaviest part of a DFI system. Steps can be considered to reduce the 
harnessing but it is essential and must be designed into the system. Miles and miles of spider 
harnessing are required for a launch vehicle. Not much can be done about harnessing short of 
implementing wireless sensors. Wireless technology brings a different set of headaches into the 
design. Strategic placement of DFI components may help reduce harness weight but this is not 
always a practical solution in NASA’s case. Expect to have many pounds of harnesses, bent pins, 
connector issues, frayed protective sheathing, short harnesses, long harnesses and the list goes on. 


Simplistic DFI Architecture 


If the DFI architecture were to be designed for a future NASA launch vehicle then how would the 
design start? There would be a need to have structural vehicle architecture. At the penning of this 
paper, NASA has not yet decided on a launch vehicle concept, propellant types or mission. So it is 
speculation as to what a launch vehicle might be. Let’s assume that NASA uses Shuttle derived 
hardware. That means, maybe, the conceptual vehicle will use solid strap-on boosters, core stage 
engines, and maybe components of the current ET (External Tank). If this vehicle is to lift heavy 
payloads, then it can be assumed that there will be a boost stage and an earth departure stage. It 
can also be assumed that the vehicle will be reconfigurable or modular. That means, if there is only a 
need to lift a crew capsule, maybe the SRBs are not needed. 
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A DFI system requirement may read as follows: 


“The launch vehicle will have a system for measuring engineering data to track vehicle performance 
and verify engineering design models.” 

For this example derived requirements may be assumed. This conceptual launch vehicle will consist 
of the following elements: 

1 . Boost stage 

a. Solid strap-on boosters 

b. Core stage engines 

c. ET-like boost stage propulsion system 

d. Unrecoverable core stage (splash and sinks) 

e. Solids are recoverable (splash and retrieved) 

2. Upper Stage 

a. ET-like main propulsion system 

b. Upper Stage engines 

c. Once consumed, the upper stage is unrecoverable (burns on reentry) 

3. Payload, 100 metric tons of stuff 

a. Payload is 1000 lbs overweight (assumed) 

Given these derived and assumed requirements, This DFI system will be very large and complicated. 
And because hardware cannot be located on the payload, it must all fit on the boost and departure 
stages. Even though this system is derived from Shuttle hardware, it is used in a different capacity on 
this vehicle. So what worked on Shuttle, might not work on this vehicle. New models will need to be 
anchored with new DFI data. 

This first bogie is to determine any DFI weight and downlink restrictions. For the simplistic 
architecture, the system can weigh what it weighs (within reason) but will have limited bandwidth to 
telemeter what it measures. This scenario is that of a realistic NASA DFI system. The system will 
need a couple of thousand of measurements, but are limited on getting that much data through the 
telemetry system before separation. Believe it or not, the telemetry system capability will balance the 
weight of the DFI system. They work in conjunction with each other. When bandwidth goes down, 
measurement count can go down. When measurement count goes down, so do sensors and 
harness weight. And finally, cost goes down. If the program can provide the bandwidth bogie, the 
system can be designed to the fullest. There can be an optimum balance between measurements 
and bandwidth, depending on format switching within the data system. 

So, one can predict that a telemetry system will be utilized on the earth departure stage. It can’t be 
placed on the payload. It’s already too heavy. It cannot be place on the boost stage because there 
are other elements depending on it when the boost stage falls away. The same is with any strap-on 
solids. They fall away with the boost stage or slightly before. A recorder can be placed on the solids 
because they are recoverable. This makes the system modular. It would be practical to send some 
critical DFI data from the solids to be telemetered, but it’s not required. A recorder should not be 
placed on the boost stage for the same reason as the telemetry system. It is not recoverable. So, can 
a recorder be placed on the upper stage? The upper stage is not recoverable. Will it be a cost 
effective measure to have one? Technically, a need may exist, at least for a short period of time. The 
data is critical. It must get to the ground and in the hands of the analysts. It is envisioned the recorder 
on the upper stage can be triggered to continuously output the last few minutes of data as the 
telemetry system continuously transmits. This would allow all ground stations and airborne assets to 
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gather as much data as it can before all is lost on its toasty reentry and consumption. Figure 2 shows 
a simplistic DFI architecture for a future launch vehicle. By no means is this rendering depicting the 
future vehicle architecture. It is only an example. 

As one can see, there are many data acquisition units on each element. It only shows 2 to 4 on each. 
But in reality, it could be more or less. This design is modular. That is, each element has its 
separate, but communicable, DFI hardware. If the solids are not required, then the system on the 
booster and upper stage still exist. If the boost stage falls away, the upper stage continues to take 
data. Maybe a tweak in the software with a format change is all that is required to refocus the 
acquisition. 

Ascent phasing is another way to increase the amount of measurements for data acquisition. During 
the ascent, the upper stage is basically dormant while the boost stage is pressing on. With a format 
switch, the boost stage separates and the upper stage data acquisition starts. This phasing will allow 
for more measurements on the vehicle while operating under the limited bandwidth of the telemetry 
system. 
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Figure 2. Simplistic DFI Architecture 


Experiences Gained 




Experiences gained are a positive connotation for the term “lessons learned”. In every 
implementation of a DFI system, obstacles are encountered that were not considered at the 
beginning of the system design. While it is easy to catch the large obstacles like vibration levels, 
sensor requirements and the like; some issues don’t surface until the system is integrated into the 
flight vehicle. One such issue encountered on Ares l-X was that of using strain gages. Strain gages 
are used every day on various platforms. If installed correctly they produce good analytical data. As 
the DFI instrumentation was installed on Ares l-X, each segment, or “tuna can” was then stacked 
upon the other forming the simulated upper stage. As each can was stacked, stress was induced on 
the strain gages. When all were stacked, the gages had so much induced strain on them that the 
data system wasn’t able to “zero” the saturated gages. A solution for future flights would be to install 
the strain gages after the vehicle is assembled. It was a programmatic decision to install the 
instrumentation as the vehicle was being built. The thought was that time will be saved in the end 
during system checkout. 

Another issue along this same thought was that once a flight data acquisition box has been tested 
and delivered, it cannot be opened and reconfigured or modified with “zeroing” resistors. The same 
goes for the pre-built harnesses. A possible solution to this would be to perform focused testing on 
each gage and to provide a resistor network design at the strain gage and just before the harness. 
Ares l-X data suffered because of the lack of “zeroing” the strain gages. Most data acquisition boxes 
have the ability to tweak parameters, but not to the extent Ares l-X experienced. 

A programmatic experience gained is having an early DFI plan from a program’s inception. In many 
cases, DFI is an afterthought. Programs are concerned with building and flying the vehicle. They are 
not concerned as to why it performs as it does. Data is king and without it, there is no design 
validation. On Ares l-X, DFI was considered in the beginning, but a contractor for the DFI or avionics 
portion of the vehicle was nearly two years late. This will squeeze the schedule and increase risk. 

Having the proper sensor, or sensor system, specified for a given measurement is paramount. Pitot 
tubes need to be oriented in the proper orientation. If not, expect was water infiltration. Speaking of 
water infiltration, choose sensors that tolerate water. l-X had certain pressure transducers that failed 
because of the presence of water. Even the vendor said the sensor can tolerate it, but they did not. 

“Test-as-you-fly and Fly-as-you-test” is by far the number one lesson learned. This is a lesson 
learned, because we caught the negative side of not doing it. All the planning in the world cannot 
answer the questions that a test can answer. A partial set-up in a lab, though better than nothing, is 
not sufficient. The entire data system needs to be tested together, before being integrated onto the 
vehicle. Do have the conceived notion that testing only after integration will save time. It is quite the 
opposite. If l-X had tested as we flew, and flew as we tested, nearly 3 months of troubleshooting 
avionics boxes, data synchronization and sensor incompatibilities would have been avoided. Plan 
ahead, and plan for a full systems integration laboratory. 

The recorder is the brains of the system. Because of unknown buffering issues with the digital 
memory card in the recorder, Ares l-X lost the final 90 seconds of data. When the vehicle splashed 
into the ocean, frayed wires shorted and the failsafe switching system turned the power off to the 
vehicle. Turn the power off, and all data in the buffer is lost and cannot be recovered. The lesson 
here is to know the recorder’s buffering ability and test it in all conditions, even the rare off-nominal 
events. This was not expected on Ares l-X, and the program lost critical data. 
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Conclusion 


Many areas of DFI design were discussed in this brief. But there may be other design features that 
may benefit a design, that weren’t mentioned. By all means know this paper is not all inclusive. 

Every system will have its own soul and particular needs. The ones mentioned herein had an impact 
on how any DFI system will be designed in the future. “Test-as-you-fly, fly-as-you-test” lesson 
learned should be pushed. This impacted the Ares l-X flight the most. It is the fact that we simplified 
this process and thus had issues in integration and test once the DFI system was installed on the 
vehicle. 

As each component is described, one needs to think about how it can be implemented into their 
design. Maybe questions were answered, and maybe more questions were generated. Whichever is 
the case, it needs to be thought about. Remember that data is King. It is the data you are after. 
Without it, the millions of dollars spend will be for naught. Perform the “due diligence” in the 
beginning of the design process and be able to roll with the punches as they happen. Doing so may 
increase chances of success. 
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